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Dear Sir: 

This Appeal is in response to the Office Action mailed October 20, 2005^^. 
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^ Appellants are filing a Notice of Appeal concurrently with the present Appeal 
Brief. Since the Notice of Appeal was filed within three months of the mailing 

date of the Office Action and the present Appeal Brief is being filed within two | 

months of the filing of the Notice of Appeal, the present Appeal Brief is timely i 

filed. Z 

^ The Office Action mailed October 20. 2005 is a non-Final Office Action. Since 3 

the Office Action presents a second rejection for the claims that were pending as i 

of October 20, 2005, Appellants have the right to appeal the rejections made in g g 

the Office Action pursuant to 37 C.F.R. § 41.31(a)(1). ~ r. 

CXJ Li. 
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L REAL PARTY IN INTEREST 

It is believed that Accenture L.L.P. is the real party of interest in this 
Appeal pursuant to the following: 1) a recorded assignment of the above- 
identified application to Andersen Consulting executed by both of the inventors 
of record and 2) a recorded assignment of the above-identified application to 
Accenture L.L.P. by Andersen Consulting. 

II. RELATED APPEALS AND INTERFERENCES 

The undersigned, John C. Freeman, is not aware of any other appeals, 
interferences or other judicial proceedings that may be related to, would directly 
affect or be directly affected by or have a bearing on the Board's decision in the 
pending Appeal. 

III. STATUS OF CLAIMS 

The status of the claims is as follows: 

Claims 1-42 are rejected under 35 U.S.C. § 103(a) for being obvious in 
view of U.S. Patent No. 6,073,104 to Field and U.S. Patent No. 5,359,509 to 
Little et al. 

Claims 43-45 are rejected under 35 U.S.C. § 103(a) for being obvious in 
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view of Field, Little et al. and U.S. Patent No. 5,862,325 to Reed et al. 

The above-nnentioned rejections of claims 1-45 are the subject of this 
Appeal. 

IV. STATUS OF AMENDMENTS 

A Response was filed on Septennber 19, 2005 regarding a Final Office 
Action mailed on July 18, 2005. A non-Final Office Action was mailed on 
October 20, 2005, which withdrew the finality of the July 18^^ Office Action. No 
Amendment or Response has been filed regarding the October 20th Office 
Action prior to the filing of the present Appeal Brief. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

An understanding of the invention of independent claims 1,15 and 29 can 
be made upon a review of the embodiments of the invention shown in Figs. 1-6 
of the specification. Note that in the description to follow, like elements will 
employ identical identification numerals. 

Fig. 1 shows an embodiment of a computer network 100 that includes 
personal or workstation computers (such as computers 110 and 120) and 
system or enterprise computers (such as server 130, system 150, and 
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system 140) (P. 5, II. 18-20). In this scenario, computers are termed client 
computers, server computers, or system computers (P. 6, II. 1-2). In 
addition, the terms "client" and "server" are used to refer to a computer's 
general role as a requestor of data (client) or provider of data (server) (P. 6, 
11. 3-4). 

Insurance host server 130 maintains a database of claim folder 
information (P. 6, II. 19-20). Claimant client 110 accesses insurance host 
server 130 to update, enter, or review claim folder information (P. 6, II. 20- 
21). Claim handler client 120 accesses insurance host server 130 in order 
to review, evaluate, and/or fulfill claim folder data (P. 6, II. 21-23). Vendor 
system 150 interconnects to insurance host server 130 through network 100 
in order to: receive order placement from insurance host server 130; update 
database information to insurance host server 130; respond to database 
access requests from insurance host server 130; and update or respond to 
status information from insurance host server 130 (P. 6, I. 23 - P. 7, I. 4). 
Insurance back office system 140 interfaces to insurance host server 130 in 
order to: receive check requests from insurance host server 130 and 
update insurance host server 130 as to the status of checks cut from the 
system (P. 7, II. 4-6). 

Fig. 2 shows a computer network containing an insurance host 
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server 130 and a claimant client 110 (P. 7, II. 14-15). In this example, a 
claimant client 110 is interconnected through network 100 to the insurance 
host server 130 (P. 7, II. 15-16). Insurance host server 130 includes 
conventional components, such as processor 235, memory 245, I/O 
controller 250, and network interface 260 (P. 8, II. 6-9). 

It will be appreciated that the present invention may be implemented 
in software which is stored as executable instructions on a computer 
readable medium on the client server and systems, such as mass storage 
devices 225 and 255, respectively, or in memories 215 and 245, 
respectively (P. 8, II. 19-22). 

Fig. 3 illustrates the hierarchy of the various levels within a claims 
folder (P. 9, L 4). Note that an insured is one who is insured by the policy; 
a claimant is one who is making a claim against the policy (P. 9, II. 5-6). 

Claims folder 300 contains all of the policy information, information 
about the insured, and information about claims for a given client (P. 9, II. 
11-13). Within a claims folder 300 are one or more policy levels 310 and 
320 (P. 9, II. 13-14). The policy level 320 contains all the information 
relevant for a given policy (P. 9, II. 17-18). 

Below policy level 320 is insured level 330 (P. 10, I. 1). Insured level 
330 contains all information relevant about the insured (P. 10, II. 1-2). 
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Below the insured level 330 is the claim level 340 (P, 10, I. 11). The 
claim level 340 has general information about the claim raised against the 
policy (P. 10, II. 11-12). The claim level 340 may include the date of the 
claim, the nature of the claim, and general information relevant to the type 
of claim (P. 10, II. 12-14). A property loss claim may include information 
about the police report or the nature of the theft (P. 10, II. 14-15). A 
medical claim contains information about the general nature of the medical 
situation (P. 10, II. 15-16). 

The claimant level 350 is below and within the claim level 340 and 
has full details about the claimant (P. 10, II. 17-18). The claimant's name, 
address, phone numbers, and other general contact information are within 
this level (P. 10, II. 18-19). 

Below and within the claimant level 350 is the line level 360 which 
details the various types of claimed damages levied by a particular 
claimant (P. 11, II. 3-4). A single claimant might have multiple types of 
claims that are represented by different lines within the line level (P. 11, 
II. 4-7). 

Systems and processes operate at the line item level 370 within the 
line level 360 (P. 11, II. 8-9). The line item level 370 includes detailed line 
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items, or line item data, for each claim against a particular line in the line 
level 360 (P. 11, II. 9-10). For instance, a property theft line claim includes 
line item data for each piece of property stolen (P. 11, II. 10-12). The line 
item data is stored within a line item database (P. 11, II. 12-13). Line item 
data fields vary depending on the nature of the item (P. 11, II. 1 3-14). 

Fig. 4 illustrates the three processes that run inside line item level 
370 (P. 11, II. 19). For example, the capture line item data process 410 
receives line item data entered by claimant client 110 or claim handler client 
120 into the line item database stored in insurance host server 130 (P. 11, 

11. 19-21). 

Fig. 5 illustrates the flow of information between the various clients 
and servers (P. 12, II. 12-13). Beginning at the top of the figure, a claimant 
on claimant client 110 operates claimant interface 500 to interact with 
insurance host server 130 (P. 12, II. 13-14). A claimant on claimant client 
110 uses claimant interface 500 to access insurance host server 130 (P. 

12, II. 21-22). The claimant accesses the insurance host server 130 after 
having "tunneled down" a website that was being accessed at one of the 
higher levels within the claims folder, e.g., from the claim level (P. 13, II. 2- 
4). Once access from claimant interface 500 to insurance host server 130 
is granted, the claimant through claimant interface 500 may enter line items 



7 



1\ 

into the line item level database in insurance host server 130, and 
insurance host server 130 may present various queries to the claimant at 
claimant interface 500 to which the claimant gives responses (P. 13, II. 4-8). 

Line item data is accessed by claim handler interface 505 from 
insurance host server 130, and evaluation information is exchanged 
between claim handler interface 505 and insurance host server 130 (P. 13, 
II. 15-18). 

Fig. 6 illustrates a flowchart of the capture line item data process 410 
(P. 14, I. 16). The capture line item data process 410 is generally initiated 
by a claimant operating on claimant client 1 10 (P. 14, II. 16-19). The capture 
line item data process 410 is initiated after the claimant has "tunneled 
down" to the line item level web screen served by the insurance host server 
130 (P. 14, II. 20-22). 

The process starts when a claimant elects (step 600) to be taken to 
an existing claim (P. 15, II. 1-2). When the process is started, the insurance 
host server 130 serves up a logon screen to claimant interface 500 (P. 15, 
II. 2-3). The claim interface 500 verifies the claim number and password to 
insurance host server 130 where insurance host server 130 accesses the 
claim level database and validates that the claim number and password are 
valid (step 606) (P. 15, II. 8-11). 
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If the claim number and password are a valid combination, various 
data from the policy level, insured level, claim level, claimant level, and line 
level is displayed in a web page served by insurance host server 130 to 
claimant interface 500 (step 608) (P. 15, II. 13-15). The data includes 
items, such as the date of the loss or injury, time of the loss or injury, policy 
number, Social Security Number of the claimant, the claimant's name, 
address and phone numbers (P. 15, II. 15-18). 

Should it be determined in step 612 that line item level data for a 
particular line level has not been previously entered, the claimant client 110 
is given the option to enter line item data via a spreadsheet (steps 624; 
626; 628; 630 and 632) or via a web-based process (steps 616; 618 and 
620) (see Fig. 6). For example, the insurance host server 130 gives the 
claimant the option of entering his data in FastPath^*^ format (step 614) (P. 
16, II. 12-13). Fast Path™ is an opportunity for the claimant to upload a 
blank, but formatted, spreadsheet from insurance host server 130 to 
claimant client 110 (P. 16. II. 13-14). Using the Fast Path™ option, the 
claimant at claimant client 110 fills in the spreadsheet with all of his line 
item level data and then uploads the spreadsheet (P. 16, II. 15-16). 

If the user selects the Fast Path™ option, the insurance host server 
130 queries the claimant client 110 to determine whether a spreadsheet 
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needs to be downloaded fronn insurance host server 130 to claimant client 
110 (step 624) (P. 16, II. 19-21). If the claimant client needs the 
appropriate spreadsheet, the insurance host server 130 determines the 
appropriate spreadsheet for that type of insurance claim (step 626), and 
downloads the appropriate spreadsheet to the claimant client 110 (step 
628) (P. 17, II. 3-6). The claimant on claimant client 110 completes the 
spreadsheet (step 630) and uploads the completed spreadsheet with all of 
the line item data into insurance host server 130 (step 632) (P. 17, II. 6-8). 
This results in the line item data being aggregated and stored in the 
insurance host server 130 (step 622) (P. 18, II. 14-15). 

If the claimant chooses to not use the FastPath™ option and to use 
the web-based process option, the insurance host server tunnels down 
through the item tree (step 616) (P. 17, II. 9-10). Stored on insurance host 
server 130 is a plurality of item trees (P. 17,11. 10-11). For each different 
type of insurance, there is a different item tree (P. 17, I. 11). For instance, 
for property insurance on a theft, the top level of the item tree may display 
groups such as electronics, jewelry, furniture, appliances, miscellaneous 
personal property, furnishings, clothing, and additional living expenses (P. 
17, II. 12-14). The insurance host server 130 chooses the appropriate item 
tree based on the line and displays the top level of that tree in a web page 
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to the claimant via claimant interface 500 (step 616) (P. 17, II. 18-20). 

The claimant tunnels through the tree of line item data until he 
reaches the line item that he or she wishes to enter (step 618) (P. 17, II. 21- 
22). The claimant enters the line item data (step 620) (P. 17, 1. 22). Line item 
data includes detailed information about the line item particular to that item 
(P. 17, I. 23). For instance, for property insurance, the line item may 
include data that includes the type of item, the location of the item in the 
home, how many of the item were stolen, the cost of the item, the year of 
purchase, the name of the owner, where the item was purchased, and 
check boxes indicating whether there are any receipts, photos, manuals, or 
other documentation that that particular item was actually in the house (P. 
18, II. 1-5). This results in the line item data are aggregated and stored in 
the insurance host server 130 (step 622) (P. 18, II. 14-15). 

The updated line item level database is displayed in summary form 
as a web page from insurance host server 130 to claimant interface 500, 
including the newly entered line item level data (step 634) (P. 18, II. 16-18). 
The claimant is able to edit specific line item level data by double clicking 
on that particular line item (step 636), thereby he or she is taken to the line 
item data entry screen and allowed to change various features of the line 
item data in the edit data block (step 640) (P. 18, II. 18-21). The claimant is 
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given the option to enter more line items (step 638) (P. 18, II. 21-22). If not, 
the capture line item data process ends (step 642) (P. 18, I. 22). 

There are no means-plus-function terms or step-plus-function terms in 
independent claims 1, 15, 29 and dependent claims 3-5, 9-12, 17-19, 23-26, 31- 
33, 37-40 and 43-45, which are argued separately below in Section VII. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

There are two grounds of rejection presented for review: 

1) the rejection of claims 1-42 for being obvious under 35 U.S.C. § 103(a) 
in view of Field and Little et al.; and 

2) the rejection of claims 43-45 for being obvious under 35 U.S.C. § 
103(a) in view of Field, Little et al. and Reed et al. 

VII. ARGUMENT 

A. 35 U.S.C. S 103 

1. Field and Little et al. 

a. Claims 1. 2. 6-8 and 12-14 

Claims 1 , 2, 6-8 and 12-14 were rejected in the Office Action of October 
20, 2005 (hereinafter "the Office Action") under 35 U.S.C. §103 as being 
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obvious in view of Field and Little et al. Appellants traverse the rejection for 



several reasons. First, independent claim 1 recites "presenting the client 

computer with an option to enter line item data regarding the claim through a 

web-based process or through a spreadsheet." Field fails to disclose this cited 

process. The Office Action has relied on the following passage of Field as 

disclosing the process: 

As illustrated in FIG. 8, the software 63 executing on 
the sentinel computer 62 at the SPE location 60 
performs a variety of functions: capturing and storing 
data from the SPE's accounting system (63a), 
transmitting to and receiving from the central location 
50 summary data (63b); and reporting program 
information to the SPE (63c). 

Central Location 

The central location 50 processes data received from 
the sentinels 42 and 62 and generates all reports. 
The reports are transferred back to both the individual 
providers and the SPE's operating agents. Data from 
the commercial paper dealer and the contract are 
entered into the system 30 at the central location 50. 
The computer system 51 at central location 50 
preferably has three types of computers. An 
input/output computer 52 is preferably an Intel 
processor, with the Microsoft "Windows for 
Workgroups" operating environment, and a database 
application developed using Microsoft's "Access" 
database program. In addition, it preferably has one 
five-hundred-megabyte hard drive, a fax/modem, a 
remote control communication software package, 
preferably International Software's Remote 
Office.TM., and a virus-screening package. During 
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the time when the I/O computer 52 is communicating 
with other offsite computers, it is disconnected from 
the local area network 54. After the I/O computer 52 
has received all of the incoming data, it transfers the 
data to primary file server 56 for processing. The 
primary file server 56 processes the data and 
transfers back reports to the computer 52 to transmit 
to the provider's sentinel system 42 or the SPE's 
sentinel system 62. Primary file server computer 56 
preferably includes an Intel processor, the Microsoft 
"Windows for Workgroups" operating environment, a 
database program comprising a routine version of the 
Microsoft "Access" database program, and a statistics 
application developed using Microsoft's "Excel" 
spreadsheet program. It also has a one-gigabyte 
hard drive. A second file server 58 is provided to 
back-up the primary file server 56. It has the same 
configuiration as the primary 
(Col. 7, II. 31-67) 

The above passage regards the processing and structure of an information 
management system 30 "that supports access of a healthcare provider or other 
receivable seller 31 to the commercial paper market 32" wherein a financial 
vehicle known as a special purpose entity (SPE) is used to issue commercial 
paper (Col. 1, II. 24-26 and Col. 5, II. 14-19) The passage is silent as to any 
computer presenting an option to enter line item data regarding an insurance 
claim through a web-based process or through a spreadsheet. While the 
passage does mention a spreadsheet, it is with respect to a statistics application 
(Col. 7, II. 63-65). The passage is silent as to entering line item data of an 
insurance claim. The passage is also silent as to entering line item data of an 
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insurance claim via a web-based process. The management system 30 of Field 
captures and manipulates data from four sources: 1) the receivable seller^s 
accounting system 36, 2) the SPE's operating agent's accounting system 38, 3) 
the SPE's commercial paper dealer 34 and 4) the contract between the SPE and 
the receivable seller 31 (FIGS. 2-5; Col. 5, II. 23-29). At best, Field describes 
capturing claim information that was previously entered into the provider's 
accounting system 36. Nowhere does Field describe the inputting of line item 
data of an insurance claim into the accounting system 36 via a web-based 
process or through a spreadsheet (Col. 8, II. 35-58). In summary, Field does not 
remotely disclose nor suggest the recited "presenting" process. 

Little et al. does not cure the deficiencies of Field in that Little et al. does 
not disclose nor suggest altering Field so that an option for entering line item 
data regarding an insurance claim via either a spreadsheet or a web-based 
process is presented. Without such suggestion, the rejection is improper. 

The rejection of claim 1 is improper for the additional reason that Field 
does not disclose nor suggest the process of querying a client computer to 
determine whether a spreadsheet appropriate for a type of insurance claim 
needs to be downloaded when a spreadsheet option is selected. The Office 
Action relies on the following passage of Field as disclosing the "querying" 
process mentioned above: 
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The first steps in implementing a commercial paper 
program, both in setting up the program and in 
running it on a day-to-day basis, is capturing claim 
data from the provider's accounting system 36. FIG. 
1 1 shows the typical flow of a patient claim from 
origination through payment as experienced by the 
provider. The claim begins with the assignment of a 
unique identification number to the patient. The 
provider then verifies that the services to be 
performed are covered by the patient's insurance, 
and the services are performed. The billing 
department consolidates the charges for all services 
performed in the provider's accounting system and 
submits the claim to the payor. The payor accepts 
the claim or, depending on the quality of the 
provider's insurance verification process, rejects the 
claim outright citing contractual issues or rejects 
specific line items in the claim. If the claim is 
rejected, it goes back to the billing department where, 
if appropriate, it is modified for resubmission. After 
acceptance by the payor, the claim is then discounted 
for contractual adjustments, and paid. FIGS. 12A and 
12B illustrate typical data fields found in electronic 
claims records stored or originating in a provider 
accounting system 36. Claim records exported from 
accounting system 36 to sentinel system 42 
preferably include substantially all the date fields 
illustrated in FIGS. 12A and 12B. 

FIG. 13 shows data structures for export files that can 
be used to export claim records or other information 
from the provider's accounting system 36 across the 
local area network 44 to the sentinel computer 42. 
Mainframe software 110 (including, but not limited to, 
the accounting software executing on the mainframe) 
generates and manipulates these export files. 
Regardless of what export file language is used, the 
export file is accompanied by an export specification 
that defines what data items are in each field in the 
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data file. The file is downloaded to the sentinel 42 
over the network 44 where it is captured by the 
sentinel system 42 using the Tools & Technologies' 
Data Junction.TM. program. The same file exporting 
technique is used to export data from an SPE's 
mainframe 66. If a single provider tracks receivables 
at geographically separate locations, the system 30 
employs sentinel systems 42 at each provider site 40. 

FIG. 14 depicts how data moves through a provider's 
accounting system. Data is initially input into the 
system through several sub-accounting systems 
(36a). Subsystems 36a each represent, for example, 
a point of data input at the provider. For example, x- 
rays are charged for through the radiology sub- 
accounting system. Accounting system 36 
aggregates all of the information for each patient off 
of the sub-accounting system 36a. This information 
is then stored in an electronic claim record on the 
computer and put onto the billing form appropriate for 
each third party payor involved with a specific patient. 
If the claim is not eligible for payment by an approved 
payor, the payor field in the claim record is set to 
"ineligible" or the like. There are two primary places 
in this flow of information through the accounting 
system to capture claim data for export by the 
provider's mainframe 46. First, the data can be 
extracted from the accounting system 36 in a batch 
mode. When the accounting system 36 is updated 
for new claims, payments on existing claims or other 
changes, the new or updated claims are flagged and 
the mainframe software 1 10 is programmed to both 
write this data to an export file and notify the sentinel 
computer system 42 of the update. 1he sentinel 
system 42 then reads the export file. Preferably, the 
export file is a standardized format so that all 
sentinels 42 receive the provider electronic claim 
recorded in the same format. The export data 
software of mainframe software 1 10 is thus 
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configured to convert data from the provider's 
accounting system format to the standardized export 
format. Alternatively, the software on sentinel 42 can 
convert the exported records to a standardized format 
upon receipt of the export file. 
(Col. 8, I. 35-Col. 9, 38) 

The above passage is silent as to querying a client computer to determine 
whether a spreadsheet appropriate for a type of insurance claim needs to be 
downloaded. Accordingly, Field does not remotely disclose nor suggest the 
recited "querying" process. 

Little et al. does not cure the deficiencies of Field in that Little et al. does 
not disclose nor suggest altering Field so that Field queries a client computer to 
determine whether a spreadsheet appropriate for a type of insurance claim 
needs to be downloaded. Without such suggestion, the rejection is improper and 
should be withdrawn. 

For the above reasons, the rejection of claim 1 is improper and should be 
withdrawn. Claims 2, 6-8 and 12-14 depend directly or indirectly on claim 1 and 
so their rejections should be withdrawn for the same reasons stated above with 
respect to claim 1 . 
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b- Claim 3 

Claim 3 was rejected in the Office Action under 35 U.S.C. §103 as being 
obvious in view of Field and Little et al. Appellants traverse the rejection for 
several reasons. First, claim 3 depends indirectly on claim 1 and so is 
patentable over Field and Little et al. for at least the same reasons given above 
in Section VILA. 1. a as to why claim 1 is patentable over the references. 

The rejection is improper for the additional reason that there is no 
motivation in either Field or Little et al. to receive a password as part of receiving 
claim identification information. The Office Action has asserted that Field 
discloses receiving a password at lines 35-58 of column 8. A review of the 
passage does not mention receiving a password. While the passage mentions 
assigning a unique identification number to the patient (Col. 8, II. 40-41) there is 
no mention that such a number is used for gaining access to any portion of the 
system. Accordingly, the recited identification number does not act as a 
password. Since Little et al. does not suggest altering Field to receive a 
password as part of receiving claim identification, the rejection is improper and 
should be withdrawn. 
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c. Claim 4 

Claim 4 was rejected in the Office Action under 35 U.S.C. §103 as being 
obvious in view of Field and Little et al. Appellants traverse the rejection for 
several reasons. First, claim 4 depends directly on claim 3 and so is patentable 
over Field and Little et al. for at least the same reasons given above in Section 
VII.A.I.b as to why claim 3 is patentable over the references. 

The rejection is improper for the additional reason that there is no 
motivation in either Field or Little et al. to validate both a password and a claim 
number. The Office Action has asserted that Field discloses receiving a 
password at lines 35-58 of column 8. A review of the passage does not mention 
validating either a password or a claim number. Furthermore, the passage 
certainly does not describe validating both a password and a claim number as 
recited in the claim. Since Little et al. does not suggest altering Field to validate 
both a password and a claim as part of receiving claim identification, the 
rejection is improper and should be withdrawn. 

d. Claim 5 

Claim 5 was rejected in the Office Action under 35 U.S.C. §103 as being 
obvious in view of Field and Little et al. Appellants traverse the rejection for 
several reasons. First, claim 5 depends directly on claim 1 and so is patentable 
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over Field and Little et al. for at least the same reasons given above in Section 



VII.A.I.a as to why claim 1 is patentable over the references. 

The rejection is improper for the additional reason that there is no 

motivation in either Field or Little et al. to issue a fraud warning during the 

receiving of claim identification information. The Office Action has conceded that 

Field does not issue a fraud warning. The Office Action has relied on a passage 

at lines 35-58 of column 7 of Little et al. as suggesting having Field issue a fraud 

warning. The passage of Little et al. is given below: 

Next, the system 20 determines whether review 
codes requiring further review are present on any line 
in the payment request (step 224). If no such review 
codes are present, the system 20 assumes that the 
entire payment request is payable and returns (step 
230). If review codes requiring further review are 
present, the system 20 processes the line item with 
the highest priority review code (step 222). The 
priority of review codes is pre-determined by the user 
of the system 20 following the perceived likelihood of 
fraud or mistake for that type of procedure or 
payment request. For example, a review code 
indicating a review for the presence of an assisting 
surgeon could be considered a higher priority than a 
review code indicating review of more than one 
surgical procedure performed on the same day for the 
same patient, and would be processed first. 

Those skilled in the art will understand that the 
examples provided herein are merely illustrative of 
the great number and combination of health care 
services, procedures and materials for which payment 
may be requested, of current medical practices and of 
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possible contractual obligations between payers, 
health care providers and patients. Each user of the 
system 20 will have its own particular review criteria 
based on contractual obligations, patient and provider 
payment request patterns, and the like. The 
examples given herein will be recognized as typical to 
those encountered within the art. 

After the system 20 processes the highest priority 
review code listed on the payment request (step 222), 
the system 20 tests the results of the review to 
determine whether the review process rejected the 
payment re- 
(Col. 7, II. 35-58) 

The above passage is silent regarding issuing a fraud warning. While the 
passage mentions determining the priority of review codes "following the 
perceived likelihood of fraud or mistake for that type of procedure or payment 
request" (Col. 7, II. 34-37), that is a far cry from suggesting issuing a fraud 
warning. Since Little et al. does not suggest altering Field to issue a fraud 
warning, the rejection is improper and should be withdrawn. 

e. Claims 9 and 11 
Claims 9 and 11 were rejected in the Office Action under 35 U.S.C. §103 
as being obvious in view of Field and Little et al. Appellants traverse the 
rejection for several reasons. First, claim 9 depends indirectly on claim 1 and so 
is patentable over Field and Little et al. for at least the same reasons given 
above in Section VILA. 1 .a as to why claim 1 is patentable over the references. 
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The rejection is improper for the additional reason that there is no 
motivation in either Field or Little et al. to display an item tree of line item data of 
an insurance claim based on the line level when a web-based process option is 
selected. The Office Action has asserted that Field discloses displaying an item 
tree when a web-based option is selected at lines 1-58 of column 8. However, 
the passage does not mention selecting a web-based process for entering line 
item data for an insurance claim. Furthermore, the passage does not mention 
displaying an item tree of a line item. Since Little et al. does not suggest altering 
Field to display an item tree of line item data of an insurance claims based on 
the line level when a web-based process option is selected, the rejection is 
improper and should be withdrawn. 

Claim 11 depends directly on claim 9 and so its rejection should be 
withdrawn for the same reasons stated above with respect to claim 9. 

f. Claim 10 

Claim 10 was rejected in the Office Action under 35 U.S.C. §103 as being 
obvious in view of Field and Little et al. Appellants traverse the rejection for 
several reasons. First, claim 10 depends directly on claim 9 and so is patentable 
over Field and Little et al. for at least the same reasons given above in Section 
VII.A.1 .e as to why claim 9 is patentable over the references. 
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The rejection is improper for the additional reason that there is no 
motivation in either Field or Little et al. to tunnel through the item tree of line item 
data of an insurance claim when a web-based process option is selected. The 
Office Action has asserted that Field discloses the recited tunneling at lines 31- 
67 of column 6. However, the passage does not mention either selecting a web- 
based process for entering line item data for an insurance claim or tunneling 
through an item tree. Since Little et al. does not suggest altering Field to tunnel 
through the item tree of line item data of an insurance claim when a web-based 
process option is selected, the rejection is improper and should be withdrawn. 

g. Claims 15, 16, 20-22, 26-30, 34-36 and 40-42 

Claims 15, 16, 20-22, 26-30, 34-36 and 40-42 were rejected in the Office 
Action under 35 U.S.C. §103 as being obvious in view of Field and Little et al. 
Appellants traverse the rejection for several reasons. First, independent claims 
15 and 29 recite either a memory for storing a program (claim 15) or a computer 
readable medium (claim 29) that contains instructions for presenting the client 
computer with an option to enter line item data through a web-based process or 
through a spreadsheet. The recited "presenting" processes are either identical 
(claim 15) or substantially similar (claim 29) to the "processing" process recited in 
claim 1. Accordingly, Field fails to disclose a program that includes instructions 
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for the cited "presenting" processes for reasons similar to those given above in 
Section VIIAI.a. 

Little et al. does not cure the deficiencies of Field in that Little et al. does 
not disclose nor suggest altering a stored program in Field so that instructions for 
presenting an option for entering line item data regarding an insurance claim via 
either a spreadsheet or a web-based process are used. Without such 
suggestion, the rejection is improper. 

The rejections of claims 15 and 29 are improper for the additional reason 
that Field does not disclose nor suggest a stored program or a computer 
readable medium that includes instructions for querying a client computer to 
determine whether a spreadsheet appropriate for a type of insurance claim 
needs to be downloaded when a spreadsheet option is selected. The recited 
"querying" processes of claims 15 and 29 are identical to the "querying" process 
recited in claim 1 . Accordingly, Field fails to disclose a program that includes 
instructions for the cited "querying" process for reasons similar to those given 
above in Section VII.A.I.a. 

Little et al. does not cure the deficiencies of Field in that Little et al. does 
not disclose nor suggest altering a stored program or a computer readable 
medium in Field so as to present instructions for querying a client computer to 
determine whether a spreadsheet appropriate for a type of insurance claim 
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needs to be downloaded. Without such suggestion, the rejection is improper and 
should be withdrawn. 

For the above reasons, the rejection of clainns 15 and 29 are improper 
and should be withdrawn. Claims 16, 20-22, 26-28, 30, 34-36 and 40-42 depend 
directly or indirectly on claims 15 and 29 and so their rejections should be 
withdrawn for the same reasons stated above with respect to claims 15 and 29. 

h- Claims 17 and 31 

Claims 17 and 31 were rejected in the Office Action under 35 U.S.C. §103 
as being obvious in view of Field and Little et al. Appellants traverse the 
rejection for several reasons. First, claims 17 and 31 depend indirectly on claims 
15 and 29, respectively, and so are patentable over Field and Little et al. for at 
least the same reasons given above in Section VII.A.1 .g as to why claims 15 and 
29 are patentable over the references. 

The rejection is improper for the additional reason that there is no 
motivation in either Field or Little et al. to have a program with instructions for 
receiving a password as part of receiving claim identification information. The 
recited "receiving" processes of claims 17 and 31 are substantially identical to 
the "receiving" process recited in claim 3. Accordingly, the rejection is improper 
for reasons similar to those given above in Section VH.A.I.b. 
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i. Claims 18 and 32 

Claims 18 and 32 were rejected in the Office Action under 35 U.S.C. §103 
as being obvious in view of Field and Little et al. Appellants traverse the 
rejection for several reasons. First, claims 18 and 32 depend directly on claims 
17 and 31 , respectively, and so are patentable over Field and Little et al. for at 
least the same reasons given above in Section VII.A.1 .h as to why claims 17 and 
31 are patentable over the references. 

The rejection is improper for the additional reason that there is no 
motivation in either Field or Little et al. to have a program with instructions for 
validating both a password and a claim number. The recited "validating" 
processes of claims 18 and 32 are substantially identical to the "validating" 
process recited in claim 4. Accordingly, the rejection is improper for reasons 
similar to those given above in Section VII.A.1 .c. 

j. Claims 19 and 33 

Claims 19 and 33 were rejected in the Office Action under 35 U.S.C. §103 
as being obvious in view of Field and Little et al. Appellants traverse the 
rejection for several reasons. First, claims 19 and 33 depend directly on claims 
15 and 29, respectively, and so are patentable over Field and Little et al. for at 
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least the same reasons given above in Section VII.A.I.g as to why claims 15 and 
29 are patentable over the references. 

The rejection is improper for the additional reason that there is no 
motivation in either Field or Little et al. to have a program with instructions for 
issuing a fraud warning during the receiving of claim identification information. 
The recited "issuing" processes of claims 19 and 33 are substantially identical to 
the "issuing" process recited in claim 5. Accordingly, the rejection is improper for 
reasons similar to those given above in Section VII.A.I.d. 

k. Claims 23, 25, 37 and 39 

Claims 23, 25, 37 and 39 were rejected in the Office Action under 35 
U.S.C. §103 as being obvious in view of Field and Little et al. Appellants 
traverse the rejection for several reasons. First, claims 23 and 37 depend 
directly on claims 15 and 29, respectively, and so are patentable over Field and 
Little et al. for at least the same reasons given above in Section VII.A.1 .g as to 
why claims 15 and 29 are patentable over the references. 

The rejection is improper for the additional reason that there is no 
motivation in either Field or Little et al. to have a program with instructions for 
displaying an item tree of line item data of an insurance claim based on the line 
level when a web-based process option is selected. The recited "displaying" 
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processes of claims 23 and 37 are substantially identical to the "displaying" 
process recited in claim 9. Accordingly, the rejection is improper for reasons 
similar to those given above in Section VII.A.I.e. 

Claims 25 and 39 depend directly on claims 23 and 37, directly, and so 
their rejections should be withdrawn for the same reasons stated above with 
respect to claims 23 and 37. 

I. Claims 24 and 38 

Claims 24 and 38 were rejected in the Office Action under 35 U.S.C. §103 
as being obvious in view of Field and Little et al. Appellants traverse the 
rejection for several reasons. First, claims 24 and 38 depend directly on claims 
23 and 37, respectively, and so are patentable over Field and Little et al. for at 
least the same reasons given above in Section VII.A.I.k as to why claims 23 and 
37 are patentable over the references. 

The rejection is improper for the additional reason that there is no 
motivation in either Field or Little et al. to have a program with instructions for 
tunneling through the item tree of line item data of an insurance claim when a 
web-based process option is selected. The recited "tunneling" processes of 
claims 24 and 38 are substantially identical to the "tunneling" process recited in 
claim 10. Accordingly, the rejection is improper for reasons similar to those 
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given above in Section VI I. A. If. 

2. Field, Little et al. and Reed at al, 
a. Claim 43 

Claim 43 was rejected in the Office Action under 35 U.S.C. §103 as being 
obvious in view of Field, Little et al. and Reed et al. Appellants traverse the 
rejection for several reasons. First, claim 43 depends directly on claim 1 . As 
pointed out in Section VII.A.I.a, Field and Little et al. each fail to suggest 
altering Field to either 1) present "the client computer with an option to enter line 
item data regarding the claim through a web-based process or through a 
spreadsheet" or 2) querying a client computer to determine whether a 
spreadsheet appropriate for a type of insurance claim needs to be downloaded 
when a spreadsheet option is selected. Since Reed et al. does not suggest such 
an alteration either, the rejection is Improper and should be withdrawn. 

The rejection is improper for the additional reason that there is no 
motivation for Field to note whether a client computer has a particular 
spreadsheet. The Office Action has conceded that both Field and Little et al. do 
not disclose the claimed process of claim 43. The Office Action asserts that 
Reed et al. suggests altering Field to use the process of claim 43. The Office 
Action has relied on a passage at column 78 of Reed et al. as suggesting Field 



30 



to note whether a client computer has a particular spreadsheet. The passage 
given below: 

Another approach to web content customization is 
commonly referred to as "cookies". A cookie is a data 
structure passed from a web server to a browser as 
part of the HTTP protocol. Cookies are produced by 
the web server and stored locally in a preferences file 
by the browser. When the user next connects to the 
web server with the browser, the web server can 
interrogate the browser for the cookie and use it to 
identify the user. The cookie can additionally store 
preference data about the user, whether entered 
manually by the user via HTML forms or collected 
automatically by the web server based on the user's 
browsing choices. Cookies are an attempt to 
surmount the manual data entry and maintenance 
requirements of the first approach above. 
Unfortunately, cookies are not directly viewable or 
editable by the consumer, nor do cookies give the 
consumer any control over the data collected or 
transmitted by the cookie. (Some browsers do give 
consumers the ability to turn off the cookie function 
altogether.) 

A communications object system overcomes these 
limitations by replacing the cookie with a 
communications object 110 from the provider. In fact 
such an improvement can be made under the existing 
HTTP protocol if a communications object exchange 
is initiated manually by the consumer during a 
browsing session by clicking on a hyperlink 
representing a communications object 1 10 on a web 
page presented by the web server. The resulting 
download of a communications object 110 can trigger 
a data exchange receipt method 141 which 
automatically transmits back to the web server any 
necessary data elements 143 from the consumer 
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database 21. This can be controlled by rules 140 
imposed by the consumer. The web server can then 
prepare and return customized content for the 
consumer program 22 to display to the browser. 
Alternatively, the web server can return another 
communications object 1 10 to repeat the information 
interchange process. In contrast to cookies, the 
consumer can be completely in control of this 
process. The consumer can view the elements 143 
of the relevant communications object; edit those 
elements 143 which involve consumer preferences; 
and apply rules 140 governing data access, data 
security, and data logging by the communications 
object. These improvements can bring rich, 
automated new forms of web content personalization 
with none of the disadvantages of cookies. 
(Col. 78, II. 25-67) 

The above passage is silent as to identifying whether a client computer has a 
particular spreadsheet. Indeed, the passage does not make any mention about 
a spreadsheet. Accordingly, Reed et al. does not suggest altering Field to 
employ the process of claim 43. For the above reasons, the rejection of claim 43 
is improper and should be withdrawn. 

b. Claims 44 and 45 
Claims 44 and 45 were rejected in the Office Action under 35 U.S.C. 
§103 as being obvious in view of Field, Little et al. and Reed et al. Appellants 
traverse the rejection for several reasons. First, claims 44 and 45 depend 
directly on claims 15 and 29, respectively. As pointed out in Section VII.A.I.g, 
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Field and Little et al. each fail to suggest altering Field to use a program that 
includes instructions for either 1) presenting the client computer with an option to 
enter line item data through a web-based process or through a spreadsheet or 2) 
querying a client computer to determine whether a spreadsheet appropriate for 
a type of insurance claim needs to be downloaded when a spreadsheet option is 
selected. Since Reed et al. does not suggest such an alteration either, the 
rejection is improper and should be withdrawn. 

The rejection is improper for the additional reason that there is no 
motivation for Field to use a program that has instructions to note whether a 
client computer has a particular spreadsheet. The Office Action has conceded 
that both Field and Little et al. do not disclose the claimed processes of claims 
44 and 45. The Office Action asserts that Reed et al. suggests altering Field to 
use the process of claims 44 and 45. The Office Action has relied on the same 
passage of Reed et al. set forth above in Section VII.A.2.a as suggesting Field to 
use a program that includes instructions to note whether a client computer has a 
particular spreadsheet. As pointed out in Section VII.A.2.a, Reed et al. does not 
suggest altering Field to employ a process with instruction to perform the 
process of claims 44 and 45. For the above reasons, the rejections of claims 44 
and 45 are improper and should be withdrawn. 

For the reasons give above, Appellants respectfully submit that the 
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rejections should be withdrawn and the claims should be allowed. 
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Chicago, Illinois 60610 
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Dated: January 20, 2006 
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VIII. CLAIMS APPENDIX 

1 . A method for capturing line item data processing system, 
comprising: 

receiving claim identification information from a client computer, 
said claim identification information identifying an insurance claim; 

presenting the client computer with an option to enter line item 
data regarding the claim through a web-based process or through a 
spreadsheet; 

when the spreadsheet option is selected: 

querying the client computer to determine whether a 
spreadsheet appropriate for the type of insurance claim needs to be 
downloaded to the client computer, the spreadsheet receives the line item 
data; 

downloading the spreadsheet appropriate for the type of 
insurance claim to the client computer; 

inserting line item data into the spreadsheet appropriate 
for the type of insurance claim; 
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aggregating the line item data collected from the client 

computer; 

storing the line item data in an insurance host server; and 
when the web-based process option is selected: 

providing the client computer with an item tree of line item 
data based on the line level; 

aggregating the line item data collected from the client 

computer; and 

storing the line item data in an insurance host server. 

2. The method of claim 1, wherein the receiving claim identification 
information further includes receiving a claim number. 

3. The method of claim 2, wherein the receiving claim identification 
information, further includes receiving a password. 

4. The method of claim 3, wherein the receiving claim identification 
information, further includes validating the password and the claim number. 

5. The method of claim 1 , wherein the receiving claim identification 
information further includes issuing a fraud warning. 
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6. The method of claim 1 , further comprising receiving information 
into the spreadsheet when the spreadsheet option is selected. 

7. The method of claim 6, wherein the aggregating comprises 
aggregating line item data in the spreadsheet when the spreadsheet option is 
selected. 

8. The method of claim 6, wherein the aggregating further 
comprises uploading the spreadsheet to the insurance host server when the 
spreadsheet option is selected. 

9. The method of claim 1, wherein the providing comprises 
displaying an item tree of line item data based on the line level when the web- 
based process option is selected. 

10. The method of claim 9, wherein the providing further comprises 
tunneling through the item tree when the web-based process option is 
selected. 

1 1 . The method of claim 9, wherein the providing further comprises 
receiving a selection of line item data from the item tree when the web-based 
process option is selected. 
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1 2. The method of claim 1 , wherein the aggregating comprises 
updating a display of line items based on claimant's selected line items when 
the web-based process option is selected. 

1 3. The method of claim 1 , further comprising updating a display of 
aggregated line item data from the insurance host server when either the 
spreadsheet or the web-based process option is selected. 

14. The method of claim 1 , further comprising editing a listing of 
aggregated line item data from the insurance host server when either the 
spreadsheet or the web-based process option is selected. 

1 5. A system for capturing line item data, comprising: 
a processor for executing programs; and 

a memory for storing a program executable by the processor, the 
stored program including instructions for: 

(i) receiving claim identification information from a 
client computer, said claim identification information comprising, a line level 
identifying an insurance claim; 
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(ii) presenting the client computer with an option to 
enter line item data regarding the claim through a web-based process or 
through a spreadsheet; 

(iii) when the web-based process option is selected: 

(a) providing the client computer with an item tree of 
line item data based on a line level; and 

(b) aggregating the line item data collected from the 

client computer; 

(iv) when the spreadsheet option is selected: 

(a) querying the client computer to determine 
whether a spreadsheet appropriate for the type of insurance claim needs to 
be downloaded; 

(b) downloading the spreadsheet appropriate for 

the insurance claim; 

(c) inserting line item data into the spreadsheet 
appropriate for the type of insurance claim; 

(d) aggregating the line item data collected from 

the client computer, and 
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(v) storing the line item data in an insurance host 
server when either the spreadsheet or the web-based process option is 
selected. 

16. The system of claim 15, wherein the receiving claim identification 
information includes receiving a claim number from the client computer. 

17. The system of claim 16, wherein the receiving claim identification 
information includes receiving a password from the client computer. 

18. The system of claim 17, wherein the receiving claim identification 
information includes validating the password and claim number. 

19. The system of claim 15, wherein the receiving claim identification 
information includes issuing a fraud warning. 

20. The system of claim 15, further comprising receiving information 
into the spreadsheet when the spreadsheet option is selected. 

21 . The system of claim 20, wherein the aggregating the line item 
data includes aggregating line item data in the spreadsheet when the 
spreadsheet option is selected. 
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22. The system of claim 20, wherein the aggregating the line item 
data includes uploading the spreadsheet to the insurance host server when 
the spreadsheet option is selected. 

23. The system of claim 15, wherein providing includes displaying an 
item tree of line item data based on the line level when the web-based 
process option is selected. 

24. The system of claim 23, wherein the providing includes tunneling 
through the item tree when the web-based process option is selected. 

25. The system of claim 23, wherein the providing includes receiving 
a selection of a line item data from the item tree when the web-based process 
option is selected. 

26. The system of claim 15, wherein the aggregating the line item 
data includes updating a display of line items based on a claimant's selected 
line items when the web-based process is selected. 

27. The system of claim 15, wherein the stored program further 
includes instructions for updating a display of aggregated line item data from 
the insurance host server. 
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28. The system of claim 15, wherein the stored program further 
includes instructions for editing a listing of aggregated line item data from the 
insurance host server. 

29. A computer readable medium containing instructions for 
controlling a computer system to perform a method for capturing line item 
data, the method comprising: 

receiving claim identification information from a client computer, 
said claim identification information comprising a line level identifying an 
insurance claim; 

presenting the client computer with an option to enter line item 
data through a web-based process or through a spreadsheet: 

when the spreadsheet option is selected: 

querying the client computer to determine whether a 
spreadsheet appropriate for the type of insurance claim needs to be 
downloaded to the client computer; 

downloading the appropriate spreadsheet to the client 
computer; inserting line item data into the spreadsheet appropriate for the 
type of insurance claim; 
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aggregating the line item data collected from the client 

computer; 

storing the line item data in an insurance host server; and 
when the web-based process is selected: 

providing the client computer with an item tree of line item 
level data based on a line level; 

aggregating the line item data collected from the client 

computer; and 

storing the line item data in an insurance host server. 

30. The computer readable medium of claim 29, wherein the 
receiving claim identification information includes receiving a claim number 
from the client computer. 

31 . The computer readable medium of claim 30, wherein the 
receiving claim identification information, further includes receiving a 
password from the client computer. 

32. The computer readable medium of claim 31 , wherein the 
receiving claim identification information, further includes the validating the 
password and the claim number. 
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33. The computer readable medium of claim 29, wherein the 
receiving claim identification information, further includes issuing a fraud 
warning. 

34. The computer readable medium of claim 29, further comprising 
receiving information into the spreadsheet when the spreadsheet option is 
selected. 

35. The computer readable medium of claim 29, wherein the 
aggregating comprises aggregating line item data in the spreadsheet when 
the spreadsheet option is selected. 

36. The computer readable medium of claim 29, wherein the 
aggregating comprises uploading the spreadsheet to the insurance host 
server when the spreadsheet option is selected. 

37. The computer readable medium of claim 29, wherein the 
providing comprises displaying an item tree of line item data based on the line 
level when the web-based process option is selected. 
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38. The computer readable medium of claim 37, wherein the 
providing further comprises tunneling through the item tree when the web- 
based process option is selected. 

39. The computer readable medium of claim 37, wherein the 
providing further comprises receiving a selection of a line item data from the 
item tree when the web-based process option is selected. 

40. The computer readable medium of claim 29, wherein the 
providing comprises updating a display of line items based on a claimant's 
selected line items when the web-based process option is selected. 

41 . The computer readable medium of claim 29, further comprising 
updating a display of aggregated line item data from the insurance host 
server. 

42. The computer readable medium of claim 29, further comprising 
editing a listing of aggregated line item data from the insurance host server. 

43. The method of claim 1 , wherein the querying performed when 
the spreadsheet option is selected comprises: 

checking a cookie on the client computer; and 
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noting whether the client computer has a particular spreadsheet. 

44. The system of claim 1 5, wherein the querying performed when 
the spreadsheet option is selected comprises instructions for: 

checking a cookie on the client computer; and 

noting whether the client computer has a particular spreadsheet. 

45. The computer readable medium of claim 29, wherein the 
querying performed when the spreadsheet option is selected comprises: 

checking a cookie on the client computer; and 

noting whether the client computer has a particular spreadsheet. 
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EVIDENCE APPENDIX 



None. 



RELATED PROCEEDINGS APPENDIX 



None. 
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